What is Technical Debt?
In the context of ecommerce, "Technical debt" refers to the prioritization of factors other than quality and long-term viability in the development and delivery of a codebase or piece of work, resulting in future losses.
When developing functionality for an ecommerce store, there are various stakeholders to satisfy, and the efficiency and longevity of a codebase is not always the primary concern.
Factors such as external investment requirements, speed of delivery, and ability for the project to accomplish a specific goal (albeit not always in the most efficient of ways) are often prioritized above the quality and longevity of the implementation.
Oftentimes, this approach provides the appearance of short-term gain, but comes with the associated expense of medium or longer term challenges relating to the way the codebase has been implemented.
In simple terms, "technical debt" is a term used to describe the losses experienced as a result of substandard code or development practices as a result of misaligned priorities at the time of development.
For example, in a situation where the speed of delivery is prioritized, the quality, longevity, and effectiveness of the codebase may be viewed as less important, resulting in a compounded negative effect on a business over time.
These losses will typically manifest themselves monetarily over the long-term, but in the short and medium term may look like:
- Unnecessary maintenance, bug fixes, refactoring
- Lost customer acquisitions or lost sales as a result of poorly performing technical implementations within the codebase or its architecture
- Lost time, as a result of internal staff having to develop less efficient workarounds to technical problems within the stack, as a result of a failure to prioritize effectiveness of the tech in favor of delivery time.
- High levels of dissatisfaction amongst employees due to poor technical processes, as a result of a substandard technical implementation which exhibits signs of tech debt.
- A less efficient system than desired or set out, overall
Codebases which are rushed, or implemented using poor development practices, are likely to require later refactoring in order to squash bugs, correct deviations from project requirements, and perform efficiently over the medium to long term.
This costs a business additional expense; sometimes more than the initial outlay would have been if the development process was approached differently.
However, when factoring for indirect losses, such as lost time (internally) and lost sales, the overall costs associated with long-term technical debt can have a substantial effect on ecommerce businesses.
A debt is accrued due to poor quality of development as a result of external pressures, and this means that code does not meet the standard desired by the developer, or required in order to ensure long-term viability.
Over time, the tech debt often compounds, become a more substantial liability resulting in a larger aggregate loss.
For businesses who struggle to ease out of the MVP or startup mindset, a growing amount of technical debt can amass itself over the medium to long term, eventually resulting in an application architecture that fails to meet the present needs of the business, where other factors have been prioritized instead.
The types of technical debt in Ecommerce
There are 4 main types of technical debt, according to Martin Fowler.
Who is Martin Fowler?
Fowler is a speaker and author within the software development sphere, having contributed to the industry for more than two decades. He has a keen interest in understanding how software systems should be architected in order to fulfill business requirements successfully.
The Technical Debt Quadrant
According to Fowler's technical debt quadrant, tech debt can be either Reckless (misinformed) or Prudent (time-sensitive), and either Deliberate (high level of awareness) or Inadvertent (low level of awareness).
Martin asserts that tech debt can either be a conscious choice (either good or bad) or as a result of ignorance (past and present).
From this, a conclusion can be made that it's better to be in a position of awareness, where technical debt is being utilized and controlled strategically, rather than a situation where money and resources are lost to unidentified tech debt eating away at your bottom line.
It also hints that there are potential scenarios where tech debt can be leveraged for positive results where employed in a controlled and strategic manner.
Risks associated with Technical Debt for E-commerce Businesses
Expensive to remedy
Once tech debt has solidified itself within application or infrastructure architecture, the cost to refactor portions of the codebase will undoubtably incur additional expense.
The expense here isn't limited to just money, but also relates to lost time, sales, and employee productivity through less-than-desirable levels of efficiency in the software.
Depending on how compounded the tech debt has become, the level of refactoring required could potentially involve lengthy development periods to overcome.
This costs a business money, and is oftentimes difficult to pitch to stakeholders due to the frequent invisibility of technical debt, and how it can become obscure deep within the way an application is architected and how it works.
Stakeholders sometimes have difficulty imagining the gains made through code refactoring, preferring instead to spend money on the development of new features or enhancements.
This complicates matters for stakeholders who do recognize the debt, and are keen to resolve it.
Overall, some stakeholders struggle to justify the additional expense incurred in order to resolve technical debt, until it becomes compounded to a point where it impacts significantly enough on operations.
This is why it's vitally important to address tech debt early in the lifecycle of a codebase (or particular part of it), whether it was deliberate or inadvertent.
For inadvertent tech debt, it's often only identified once the issue has compounded itself to a point where it infringes on other operations, and a "quick-fix" in this case would only serve to mask the issue, allowing it to further brew.
Potential to Impact Customer Experience
There is a risk with some types of technical debt that impacts will be felt on the consumer side, particularly in ecommerce.
With online retail, consumers are the driving force behind revenues, and their experience forms a key component in turnover for an ecommerce store. Priority should always be placed on consumer experience, and for ecommerce businesses this is even more vital.
Where enamored technical debt is eating away at key metrics such as website response time, or causing buggy on-site experiences and unpredictable application behavior, customer experience and satisfaction can be expected to take a significant hit. This will, most likely, have a direct impact on sales in the form of high bounce rates and page abandonment.
Site speed, as well as buggy user experience, are key determining factors in user satisfaction, and this is prevalent regardless of the user's device.
Over the longer-term, digital merchants can invariably suffer from a loss of loyal, repeat buyers due to persistent frontend latency or bugginess, which can oftentimes be a direct result of unaddressed technical debt. We see this often where brands have struggled to transition their product or service outside of a startup or MVP mentality. In this case, frontends are frequently riddled with minor bugs, and failure to address backend bottlenecks has resulted in sub-prime response times; sometimes as high as 10 seconds (and maybe more).
By the time technical debt is manifesting itself on the frontend, and thus impacting user experience, it is likely to be fairly enamored throughout the entire application, or indeed the whole stack. This is why it's prudent to take action against technical debt early on, and to a sufficient extent.
A Continuous Drain on Resources
It's expensive to maintain a technical deficit within an application's codebase, and this is particularly true for ecommerce and online retail.
Debt needs to be repaid. And in the form of technical debt, organizations will make remittance in terms of lost time and money; both directly and indirectly.
As for direct losses, businesses lose time and funds in the form of deploying workarounds, quick fixes, and dodgy patches in order to maintain a software system or infrastructure that is no longer up-to-par.
Where losses are indirect, this happens either when the tech debt has been consciously ignored ("we have bigger priorities right now"), or the organization is unaware ("we didn't know the codebase was costing us more to run than it should have"; "we didn't know this kind of automation could be done").
When is Technical Debt OK?
Technical debt is not always a negative thing. There are some instances where technical debt is acceptable, or even somewhat desirable, but these scenarios shouldn't be exploited.
Consciously developing an MVP
Maintaining a position of tech debt often makes sense for minimum viable products and early-stage startups. By consciously testing the tech, startups and MVPs have the opportunity to prototype an application and demonstrate proof-of-concept, without necessarily committing to the full technical expense of realizing the app as a viable production build.
In this case, maintaining a tech debt allows the startup to better allocate these funds to alternative areas.
In the case of MVP development, implementations by definition can be somewhat lacking in efficiency and maturity. This is often desirable (hence the name "minimum viable product"), but care should be taken when moving the website, product, or service out of MVP status.
A common mistake made by digital businesses is failure to adequately refactor and refine an MVP codebase or stack to move into production.
This has the potential to lead to a codebase running in production which is simply not fit for purpose, and will cost the business in both direct and indirect losses over the medium term.
Long term, it would be almost imperative that the application is refactored appropriately, because it's more than likely that the tech debt will be widespread and unconfined.
Ecommerce businesses should take particular care to direct sufficient budget and resources to the maintenance of their applications, infrastructure, and any other component of their technology stack.
Much in the same way that buildings and roads require regular maintenance, as do tech implementations, particularly where consumers are the business' biggest revenue drivers.
When a plan is in-place for repaying the technical debt
Short-term technical debt for more established ecommerce businesses can be helpful in determining the viability of new features, and for testing implementations prior to making a long-term commitment.
It goes without saying that these kinds of operations should be undertaken sensibly and with care, so as to avoid hindering the experience of existing customers.
How to Mitigate Against Technical Debt in E-commerce
There are various ways that technical debt can be accrued, and for ecommerce businesses it's particularly important to put mechanisms in place to avoid it.
The avoidance of negative technical debt can largely be managed through sufficient oversight and actioning through development and maintenance cycles.
Scope ecommerce projects correctly and adequately
Identifying all areas of project scope is a key factor for success to any development project, but it's a particularly nuanced exercise where ecommerce and digital sales is concerned.
This is because there are so many moving parts to ecommerce, and these are heavily interwoven with each other. The digital systems utilized for warehousing, inventory, and fulfillment, for example, are so closely connected to the experience of the consumer, as well as that of internal staff and employees—there's little-to-no wiggle room for shortcuts or operational bottlenecks in the form of the tech stack. Today's digital consumers demand transparency from ecommerce businesses, and cracks in backend operations will inevitably be felt by end-users in the form of delays, lack of information, and an unreliable experience.
Unanticipated technical debt can surprise both developers and ecommerce businesses where insufficient scoping was conducted at the beginning of, or during the development cycle. This can unfortunately result due to assumption-making or a failure to make requirements or deliverables clear, and is ultimately the joint responsibility of both the client and the development company.
Where functionalities or integrations have not been adequately scoped, rushed or sub-par implementation is likely to result in a future deficit, in the case where sufficient funds are not available for adequate development.
Teams should approach ecommerce development projects using a multifaceted approach, paying thought to the experience of each type of user, including internal administrative staff. The development of clear, concise user stories for each type of user can aid in the discovery of otherwise hidden requirements, but should also be architected out into a full business requirements sheet and clear project deliverables.
Adequate scoping can help alleviate technical debt for ecommerce businesses by affording sufficient development time, budget, and resources to all required functionalities and integrations. As a result, the entire experience is more thought-out, and the system is built to a standard of requirements that addresses the business' unique needs.
Provide sufficient time for development completion
A responsibility of both the client and the development & technology partner is to ensure that adequate timeframes are in place for the development and architecting of the ecommerce system.
The nuanced and intricate nature of modern ecommerce builds denotes a high level of interoperability between systems (think decoupled frontend; multiple backend data sources; specialist inventory management; integrated fulfillment, label printing, and shipments through a WMS or similar).
As ecommerce builds become ever-more bespoke in their implementations, it's imperative that sufficient time is allocated so that the development cycle is not rushed or shipped prematurely.
Review your ecommerce stack at set intervals to assess the extent to which the implementation still serves the business
Ecommerce stacks that were originally built as MVPs should receive code and implementation reviews periodically, to assess the extent to which the stack still serves the project/business.
This is true for individual feature builds for more established e-commerce stores as well.
Through reviewing code at set intervals, an opportunity to scrutinize the efficacy and overall performance of the application provides a clear route to any potential action that needs to be taken.
Even for non-MVP builds, incorporating a frequent, structured review process into your team's workflow will do wonders to ensure that integrations remain stable; code remains secure; and preexisting functionality is still serving the business and end consumers well.
Education
In our experience as a development agency, education plays a pivotal role in the avoidance and mitigation of technical debt for our e-commerce clients.
Oftentimes, key stakeholders or decision makers are simply not aware of the extent to which maintaining a long technical debt impacts business, both in terms of operations and end consumers.
It's also possible that education is needed around the benefits of further digital transformation, and the ways in which processes can be optimized in order to ease internal workflows and efficiency of the frontend for online shoppers. As a result of the avoidance and mitigation of ecommerce-related tech debt, systems cost the business less money to run, and less billable development hours are required in order to maintain legacy or outdated/unsuitable implementations.
Sometimes, development budget is not the primary barrier in mitigation of e-commerce-related technical debt, but rather a clear understanding of how and why current or impeding deficit needs to be avoided for the benefit of the retailer and its online shoppers.